As is well known to those skilled in the art, a conventional Trusted Platform Module (TPM) is a hardware device or “chip” that provides a secure crypto-processor. More specifically, a typical TPM chip generally offers facilities for the secure generation of cryptographic keys, and limitation of their use, in addition to a hardware pseudo-random number generator. It also includes capabilities such as “remote attestation” and sealed storage. Remote attestation is intended to create a practically un-forgeable summary of a particular software, firmware and/or hardware configuration. The extent of the summary is decided by the components involved in measuring the software, firmware and/or hardware configuration. This allows a third party to verify that the software, firmware and/or hardware configuration complies with some set policy. “Binding” certifies data using a TPM endorsement key, a unique key burned into the TPM chip during its production, or another trusted key descended from it. “Sealing” encrypts data similar to binding, but in addition specifies the state in which the TPM chip must be in order for the data to be decrypted or “unsealed.”
TPM chips are also used to authenticate computing devices. Since each TPM chip has a unique and secret key burned in as it is produced, it is capable of performing platform authentication. For example, it can be used to verify that a system seeking access is an expected or authorized system. Clearly, pushing the security down to the hardware level of a system, by using discrete TPM chips in conjunction with corresponding security software, provides more protection than a software-only solution. However even when a TPM chip is used, keys are still vulnerable once exposed by the TPM chip to applications, as has been illustrated in the case of a conventional cold boot attack.
Many conventional solutions for implementing a TPM for a computing device involve integrating a discrete TPM chip into the motherboard or system board of such computing devices, which can also be referred to as computing systems. Unfortunately, such solutions face several challenges. For example, integrating TPM chips into a typical motherboard design results in an increased bill of materials (BOM) cost in the order of about $1 to $2 per system. However, even such relatively low per-device costs can add to a very large total considering the tremendous volume of computing devices being manufactured around the world. Another challenge often associated with conventional TPM chips is that discrete TPMs are generally not optimized for energy efficiency, and can impact the power budget for low-power systems (e.g., portable computing devices, PDA's, tablets, netbooks, mobile phones, etc.). Further, due to BOM constraints, discrete TPM chips are often implemented with relatively slow (and thus low cost) processors which negatively impacts or potentially prevents certain usage scenarios.
Consequently, because TPMs are generally considered to be optional system components, the additional monetary and power costs for including a discrete TPM chip in a system often leads to the exclusion of such devices during the manufacturing process. TPM chips are therefore not ubiquitous which makes it difficult for software or operating system developers to invest substantial resources in broad TPM usage scenarios. Another issue affecting broad TPM usage scenarios is that many conventional discrete TPM chips are not compatible with some form factors (e.g., phones, PDA's, tablets, etc.). In fact, many conventional devices such as mobile phones and tablet type computers don't generally use discrete TPM chips, and in some cases may not have the appropriate interconnects (e.g., an LPC bus) to support the use of discrete TPM chips with the system-on-a-chip (SoC) driving devices such as phones or tablets.
A discrete TPM chip, which can also be referred to as a hardware TPM or a TPM security device, also has the disadvantage that it could be desoldered from a computing device and fed arbitrary measurements, making it unsuitable as a means to withstand even an unsophisticated physical attack on the hardware. Another disadvantage of a discrete TPM chip is that if a new version of TPM functionality is required, an already manufactured and deployed discrete TPM chip cannot be upgraded to include the new TPM functionality. For example, if TPM 2.0 functionality is required, a discrete TPM chip that was not manufactured to include TPM 2.0 functionality cannot be used.
One alternative to a discrete TPM chip for use with a SoC, is to design the TPM functionality as part of the SoC. Such a TPM implementation would advantageously not be susceptible to desoldering attack. However, designing TPM functionality into a SoC would likely significantly increase the cost the SoC, e.g., due to the need to add an additional layer of silicon that would be necessary for the non-volatile storage required by the TPM as part of the SoC.
Another alternative to a discrete TPM chip is implementing TPM functionality in firmware. While this technique works very well, TPM functionality does not become available until relatively late in a boot cycle of a computing device, after some potentially vulnerably firmware components have already been executed.